It is common to have a family of programs and data that are intertwined in their relationship and their execution, such that a high rate of switching is essential among the different programs and there is shared use of the databases in the family. Such a family of programs and data are often supported by a software subsystem (operating under an operating system). The subsystem often handles a large number of transactions that are concurrently accessing a large number of different programs and databases in the family. For example, the transactions of banking tellers (both humans and machines) in a multi-branch banking complex may concurrently use deposit programs and withdrawal programs (that share the same database, i.e., customer accounts), credit check programs and their databases, and numerous other related banking programs and databases, all of which are being accessed concurrently by a set of transaction programs invoked by individual requests for service.
Such programs and data have been found to be usable at their fastest potential rate when they are all in a single address space (AS) being accessed from one or more CPUs. However, subsequent experience has indicated significant failures in the execution of such programs, due to incorrect store operations by an executing program wiping out part of another or a database. Such execution failures have temporarily terminated the operation of a multi-branch banking business dependent on such a system. A programming system failure that causes a temporary outage of an entire business is usually considered a non-tolerable option, regardless of its speed of operation. Also, incorrect store operations that do not result in a system failure, but invalidly modify data and perpetuate without being detected are non-tolerable, difficult to detect program failures.
One way to prevent such program failures is to isolate the different programs and databases from each other in their system, so that one program cannot access another program or database in the system. One such storage isolation approach is presented in commonly assigned U.S. Pat. No. 5,361,356, by Clark et al., entitled “Storage Isolation With Subspace-Group Facility,” the entirety of which is hereby incorporated herein by reference.
In this prior patent, a Branch in Subspace Group (BSG) instruction is executed in problem state (for example by an application program) for providing a fast instruction branch between address spaces within a restricted group of address spaces called a subspace group. The subspace group contains two types of address spaces: a base space and any number of subspaces. The subspace group is set up in a control table associated with each dispatchable unit (DU). This DU control table contains: an identifier of a base space, an identifier of an access list that contains identifiers of all subspaces in the subspace group, an indicator of whether CPU control was last given to a subspace or to the base space, and an identifier of a last entered subspace in the group. The BSG instruction has an operand defining a general register containing the target virtual address and an associated access register containing an access-list-entry token (ALET) defining the target address space. The ALET indexes to a target subspace identifier in the access list, and then the associated virtual address locates the target instruction in the identified target address space. BSG instruction execution controls restrict the BSG branching only to an instruction in the subspace group.
Applicants have discovered that one restriction on the above-noted process is that secured subspace isolation was achieved only for primary and secondary space addressing, and not achieved for access register addressing while running with subspace active. Prohibiting the usage of access register addressing allows for a secure subspace environment, but limits the general applicability of secured subspaces on many systems, such as an International Business Machines S/390 Operating System. IBM markets a transaction manager which runs on S/390 and is referred to as Customer Information Systems (CICS). A CICS's direction to use subspaces for transaction isolation within an open transaction environment (OTE) for CICS applications would not be consistent nor acceptable unless access register addressing is available for the CICS applications and resource managers that the applications called.
In view of the above, applicants have discovered there is a need in the art to further extend the teachings of subspace isolation to allow usage thereof in an access register addressing mode with secured subspace isolation.